Over the years, through folklore, uncertainty, misunderstanding and possibly unexamined statements, many myths have spread about the viability of object databases in commercial settings. These myths have covered a variety of issues ranging from performance to scalability to the actual workability of an object database. It is unfortunate that the proliferation of myths occur in scientific settings of research, development, and deployment as more time is spent debating mundane superficialities (which are obvious to the well-informed) than is spent discussing the real stimulating issues which bring people closer toward achievement and discovery.

One possible reason that myths about object databases have spread has to do with untimely knowledge. When the products first arose in the 1980s, they were considered academic novelties, which were not ready to meet the needs of everyday users. Technology progressed, however, and object database companies started to deploy their ODBMS products in the early 1990s. ODBMS products have been in the enterprise for a few years now. Unfortunately, some of the people who review object databases in the press still use their anachronistic knowledge of the past as a basis for their reviews. Even worse, once a reviewer discovers that a particular product cannot do something, a general statement is made about all the products in the genre which may not be true. That is like saying if a particular car company does not provide anti-lock brakes, all car companies do not provide anti-lock brakes. Misinformed generalizations help proliferate myths.

What follows is a non-exhaustive list of some of the myths that have spread over the years that are still around. Yes, because you are viewing the Versant Web page, some of the discussions are taken from the Versant experience. However, the intent is to understand and enlighten ourselves of the larger issues. Feel free to send another "myth" to us and we'll attempt to debunk it.

	OBJECT DATABASES DO NOT PERFORM WELL
	OBJECT DATABASES DO NOT SCALE
	OBJECT DATABASES CAN NOT PERFORM QUERIES
	NO ONE REALLY USES OBJECT DATABASES FOR REAL APPLICATIONS
	OBJECT DATABASES CAN NOT BE USED FOR TRANSACTION PROCESSING
	OBJECT DATABASES ARE JUST PERSISTENT FEATURES FOR LANGUAGES
	OBJECT DATABASES CAN ONLY BE USED WITH OBJECT-ORIENTED LANGUAGES
	OBJECT DATABASES CAN NOT ACTIVELY TRIGGER EVENTS

OBJECT DATABASES DO NOT PERFORM WELL

This is probably one of the oldest myths which needs to be "dymythed." The performance of an object database can be faster than its relational counterpart. In order to traverse from one object to another, the concept of pointer or link navigation is utilized. Not forced to perform time-inefficient joins, the object database can take advantage of the fact that relations of arbitrary complexity can be defined for classes. Complex relations and normalizations in an RDBMS setting may have severe performance ramifications when performing joins. Furthermore, object databases have the concept of client caches which store recently accessed objects. This is an almost non-existent concept in traditional databases, and can greatly enhance the performance of object databases.

OBJECT DATABASES HAVE SCALABILITY PROBLEMS.

Although some ODBMS products in the past have suffered scalability problems, there is no reason to generalize this for all ODBMS products. A limitation for scalability can usually be linked to database architecture decisions. A Versant database system, which is object aware and uses logical immutable object identifiers, can have limits up to 65,000 databases per network and 281 tera-objects per database. In production, Versant has been used with a 50 GB database. An object based object database is supposed to sustain peformance when its size increases.

In the case of the Versant ODBMS, the product does not use a memory page map architecture. The Storage Management part of Versant has a similar architecture to that of the latest version of some of its relational counterparts. Whatever makes a relational database scalable can make Versant scalable. Because objects can hold complex data besides just strings and ordinal values, the scalability has the potential to be better than relational databases for certain types of applications. For example, if a user were to create a database of all of the billions of galaxies and billions of stars in the universe, does it not make sense to use an object database which can scale to such astronomical proportions?

OBJECT DATABASES CANNOT PERFORM QUERIES.

What good is a database if the contents of the database cannot be retrieved? Queries for object databases are usually performed via the host language of the application which is a front end to the database. Programming lanaguages such as C++, Smalltalk, or Eiffel provide for powerful control structures and iterators when performing queries. The concept of value based indexing is also used to speed up access time. The indexes are dynamically mantained by the ODBMS. While it is true that the requirements for OQL (Object Query Language) are still being finalized by ODMG to perform ad-hoc queries, there do exist products on the market which allow query mechanisms through other interfaces. VERSANT/M, an ODBC driver, is one such tool. In this type of set-up, Versant can perform ad-hoc queries on the back end of a client/server architecture similar to what a relational database already does. (By default, Versant performs queries on the backend. See the September 1995 Versant ODBMS Tip of the Month web page for more details).

NO ONE REALLY USES OBJECT DATABASES FOR REAL APPLICATIONS.

Object databases are used in many real-world mission critical applications such as billing systems, portfolio management, network management, customer care, telephone switches, power grids, etc.. Just think about the amount of money a telephone company can lose if a switch goes down because its database cannot perform to meet the expectations of the switch. The Versant ODBMS has been deployed in power grids for an electric company. If the Versant ODBMS is utilized in such settings, it is obvious that it must be a robust product. Moreover, many companies that do get to this point consider their use of Versant a key part of their competitive advantage.

OBJECT DATABASES CANNOT BE USED FOR TRANSACTION PROCESSING.

This is simply not true. In the RDBMS world, a simple select statement can be viewed as a transaction. In an ODMBS system, transactions can be arbitrarily complex as the host programming language allows them to be and are not limited to just using SQL or embedded SQL statements. In fact, in one particular Versant benchmark for a reservation system, the ODBMS out-performed the once powerful mainframe with its traditional database used for transaction processing.

OBJECT DATABASES ARE JUST PERSISTENT FEATURES FOR LANGUAGES.

Because object databases are tightly coupled with object oriented languages, some people have viewed them as being only persistent storage managers. On the other hand, a database is supposed to be able to handle concurrent users with locking, multiple transactions, levels of distribution, platform heterogenity, automatic backups and restorations, garbage collection of disk space, and efficient schema evolution. An ODBMS, by defintion, does that and other tasks such as support for work group computing and versioning of objects. In Versant, there is a facility which performs automatic space compaction to relieve the effects of disk fragmentation in order to sustain performance. This is a feature of any good DBMS. The Versant ODBMS can provide for a full fledged synchronous fault tolerant server for "hot standby" database redundancy, a relatively modern concept in database technology.

OBJECT DATABASES CAN ONLY BE USED WITH OBJECT ORIENTED LANGUAGES.

This doesn't get mentioned much anymore, but is worth discussing briefly. First of all, if a user is going to program an application which uses an object database, it makes sense to use an object oriented language to avoid an impedance mismatch. However, this is not an ultimatum. You can also use languages such as C with an object database. In fact, one of the first object databases which MIT was experimenting with actually used LISP.

OBJECT DATABASES CANNOT ACTIVELY TRIGGER EVENTS.

In the world of RDBMS, people are used to working with stored procedures and triggers. In the ODBMS world, there is an analogous concept called event notification, albeit, it is not necessarily the same thing as it applies to objects as well as user defined events. In the Versant ODMBS, event notification is built into the product itself as users do not have to write their own polling routines and can register events of interest. These events can even be predicate based as the matching criteria of a predicate can trigger an event.

Send comments to Nimish Doshi at: nimishd@versant.com

[ What's New | Products | Partners | Tech Support | About Us | Employment | Contact Us | Search | Home ]
[ C++ Solutions | SmallTalk Solutions | Internet Solutions ]